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DETAILED ACTION 

Remarks 

1 . In response to communications filed on 1 0 June 2009, claim 1 7 is 
amended. Claims 1, 3-17, and 19-26 are pending in the application. 



Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 102 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

3. Claims 1, 6, 17, and 21-25 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Whiting et al . (US Patent 5,778,395), in view of Fuiibavashi 
(US Pre-Grant Publication 2003/0131278) further in view of Zavas et al . (US 
Patent 6,560,615). 



As to claim 1 , Whiting et al . teaches a data protection system, comprising: 
A fileserver configured to contain shares of data and to be connected with 
a repository (see 7:8-19 and 7:59-8:20), 
The fileserver includes: 

A filter driver operative to intercept input or output activity initiated by client 
file requests (see Whiting et al . 7:8-19 and 7:59-8:20) 
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a file system in communication with the filter driver and operative to store 
client files (see Whiting et al . 7:8-19); 

The filter driver is configured to capture the snapshot at a specified time 
interval based on a backup frequency defined in a protection policy stored in the 
fileserver, wherein the protection policy is configured to be uniquely defined for 
each share of data on the fileserver (see Whiting et al . 5:2-8 and 7:17-24. Each 
node has its own share of data, wherein each node can set its own protection 
policy). 

Whiting et al . does not explicitly teach wherein two or more repositories 
are configured to store a replica of a file, wherein a storage location and a 
number of replicas in each repository can be configured to change over time; 

Fujibavashi teaches wherein two or more repositories are configured to 
store a replica of a file, wherein a storage location and a number of replicas in 
each repository can be configured to change overtime (see paragraphs [0019]- 
[0020]. A local storage is connected to a remote storage, to which it mirrors the 
data it stores. The remote storage snapshots contain copies of the local storage 
snapshots. The storage location is configured to change over time, as volumes 
are added and replace other volumes. The number of copies is configured to 
change over time, as more volumes are added from 1 to N); 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have modified Whiting et al . by the teachings 
of Fujibavashi . because Fujibavashi provides Whiting et al . the benefit of locating 
data backups remotely, so that a customer can survive a disaster by restoring 
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data using backed up data mirrored in a remote location that was unaffected by 
the disaster (see Fujibavashi paragraph [0002]). 

Whiting et al . and Fujibavashi do not teach and further configured to 
capture a snapshot of a set of the shares of data at a particular point in time and 
to maintain a list of modified and/or created files since a last snapshot occurred. 

Zavas et al . teaches and further configured to capture a snapshot of a set 
of the shares of data at a particular point in time and to maintain a list of modified 
and/or created files since a last snapshot occurred (see 5:31-40 and 7:16-46); 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have modified Whiting et al . and Fujibavashi 
by the teaching of Zavas et al ., because Zavas et al . provides the benefit of 
insertion and removal of entries in the MFL being performed by the storage 
system. When the first of a file's data and metadata bits are turned on, the 
storage system adds the file to the MFL. In this way, a file is added only once to 
the MFL (see 7:40-45) which greatly reduces the already low computer system 
overhead imposed by MFL maintenance (see 8:2-4). 

As to claim 6, Whiting et al . as modified teaches: wherein the fileserver, 
based on the protection policy, is adapted to define repositories used for storage 
of files (see Whiting et al . 7:59-8:20), frequency of data backup (see Whiting et 
al. 5:2-8 and 33:49-51), how many replicas are maintained within each repository 
(see Whiting et al . 8:16-20), and how modifications to share data are maintained 
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As to claim 17, Whiting et al . teaches a data protection system comprising: 
A fileserver configured to contain shares of data and to be connected with 
a repository (see 7:8-19 and 7:59-8:20) 
Said fileserver includes: 

Filter driver means for intercepting input or output activity initiated by client 
file requests (see 7:8-19 and 7:59-8:20) 

File system means in communication with the filter driver, the file system 
means for storing client files (see Whiting et al . 7:8-19); 

Wherein said filter driver means is configured to capture the snapshot at a 
specified time interval based on a backup frequency defined in a protection policy 
stored in the file server, wherein the protection policy is configured to be uniquely 
defined each share of data on the file server (see Whiting et al . 5:2-8 and 7:17- 
24. Each node has its own share of data, wherein each node can set its own 
protection policy), 

Whiting et al . does not teach wherein two or more repositories are 
configured to store a replica of a file, wherein a storage location and a number of 
replicas in each repository can be configured to change over time; 

Fujibavashi teaches wherein two or more repositories are configured to 
store a replica of a file, wherein a storage location and a number of replicas in 
each repository can be configured to change overtime (see paragraphs [0019]- 
[0020]); 
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Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have modified Whiting et al . by the teachings 
of Fujibavashi , because Fujibavashi provides Whiting et al . the benefit of locating 
data backups remotely, so that a customer can survive a disaster by restoring 
data using backed up data mirrored in a remote location that was unaffected by 
the disaster (see Fujibavashi paragraph [0002]). 

Whiting et al . and Fujibavashi do not teach and for capturing a snapshot of 
a set of the shares of data at a particular point in time and for maintaining a list of 
modified and/or created files since a last snapshot occurred 

Zayas et al . teaches and for capturing a snapshot of a set of the shares of 
data at a particular point in time and for maintaining a list of modified and/or 
created files since a last snapshot occurred (see 5:31-40 and 7:16-46) 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have modified Whiting et al . and Fujibavashi 
by the teaching of Zavas et al ., because Zavas et al . provides the benefit of 
insertion and removal of entries in the MFL being performed by the storage 
system. When the first of a file's data and metadata bits are turned on, the 
storage system adds the file to the MFL. In this way, a file is added only once to 
the MFL (see 7:40-45) which greatly reduces the already low computer system 
overhead imposed by MFL maintenance (see 8:2-4). 



As to claim 21, Whiting et al . as modified teaches wherein, based on the 
protection policy, the fileserver is further configured to determine whether to 



Application/Control Number: 10/659,129 Page 7 

Art Unit: 2164 

purge a file from a repository after the file has been deleted from a set of files 
(see Zavas et al . 7:11-15 and 8:5-14). 

As to claim 22, Whiting et al . as modified teaches wherein, based on the 
protection policy, the fileserver is further configured to determine whether to keep 
a version history of a file in the set of files (see Whiting et al . 7:59-8:20 and 
34:24-36). 

As to claim 23, Whiting et al . as modified teaches wherein, based on the 
protection policy, the fileserver is further configured to determine a specified 
backup frequency for a repository (see Whiting et al . 5:2-8 and 33:49-51 ). 

As to claim 24, Whiting et al . as modified teaches wherein, based on the 
protection policy, the fileserver is further configured to determine a specified type 
of compression for a file in the set of files (see Whiting et al . 8:21 -40). 

As to claim 25, Whiting et al . as modified teaches wherein, based on the 
protection policy, the fileserver is further configured to determine a specified 
caching level of a repository (see Whiting et al . 6:52-7:2). 



4. Claims 3-5 and 20 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Whiting et al . (US Patent 5,778,395), in view of Fujibavashi 
(US Pre-Grant Publication 2003/0131278), in view of Zavas et al . (US Patent 
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6,560,615), and further in view of Belknap et al . (US Pre-Grant Publication 
2003/0070001). 

As to claim 3, Whiting et al . as modified teaches the system of claim 1 . 

Whiting et al . as modified does not teach a location cache configured to 
determine based on the protection policy which repository will be used to protect 
each share of data; 

Belknap et al . teaches a location cache configured to determine based on 
the protection policy which repository will be used to protect each share of data 
(see paragraphs [0063]-[0064]). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have further modified Whiting et al . by the 
teaching of Belknap et al .. because Belknap et al . teaches the benefit of a 
common interface to media servers which conceals the media server specific 
device commands from applications which interact with the media servers 
included within the system (see paragraph [0006]). 

Whiting et al . as modified teaches a location manager coupled to the 
location cache and operative to update the location cache when the fileserver 
protects a new share of data in a specific repository node (see Belknap et al . 
paragraph [0069]). 



As to claim 4, Whiting et al . as modified teaches: 



Application/Control Number: 10/659,129 
Art Unit: 2164 

A local repository in communication with the fileserver and adapted for 
receiving files from the fileserver (see Whiting et al . 7:59-8:20. Whiting et al . 
transfers items from a local database to a remote one): 

A local repository node API adapted for communicating with the fileserver 
API (see Whiting et al . 7:59-8:20); 

The local repository is further adapted to receive replicated files from the 
fileserver (see Whiting et al . 7:59-8:20); and 

The local repository includes a protection policy component operative to 
determine whether new versions of existing files should be compressed and 
whether older versions of exiting files should be maintained (see Whiting et al . 
7:59-8:20 and 34:24-36). 

As to claim 5, Whiting et al . as modified teaches: 

A remote repository in communication with the local repository and 

adapted for receiving files from the local repository (see Belknap et al . paragraph 

[0066] and Whiting et al . 6:52-7:2): 

The remote repository is further adapted to receive replicated files from 

the local repository (see Belknap et al . paragraph [0066] and Whiting et al . 6:52- 

7:2); 

The remote repository includes a protection policy component operative to 
determine whether new versions of existing files should be compressed and 
whether older versions of existing files should be maintained (see Whiting et al . 
7:59-8:20 and 34:24-36). 
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As to claim 20, Whiting et al . as modified teaches based in the protection 
policy, the fileserver is configured to determine the location of repositories a 
number of replicas of the files to be stored in each repository (see Whiting et al . 
8:16-20). 

Whiting et al . as modified does not teach wherein, based in the protection 
policy, the fileserver is configured to determine the location of repositories 

Belknap et al . teaches wherein, based in the protection policy, the 
fileserver is configured to determine the location of repositories (see paragraphs 
[0063]-[0064]) 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have further modified Whiting et al . by the 
teaching of Belknap et al .. because Belknap et al . teaches the benefit of a 
common interface to media servers which conceals the media server specific 
device commands from applications which interact with the media servers 
included within the system (see paragraph [0006]). 

5. Claims 7-10, 13-16, and 26 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Parker et al . (US Patent 6,847,982) in view of Zavas et al . (US 
Patent 6,560,615), and further in view of Fujibavashi (US Pre-Grant Publication 
2003/0131278). 
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As to claim 7, Parker et al . teaches a method for protecting data 
comprising: 

Storing a version of a file within a set of files on a primary disk storage 
system (see 7:24-35); 

capturing files based on a backup frequency defined in a protection policy 
(see Parker et al . 7:32-34 and 9:6-1 1); 

Examining the protection policy associated with a set of files to determine 
where and how to protect files associated with the set of files (see Parker et al . 
7:34-35 and 9:23); and 

Replicating the version of the file to two or more repositories specified by 
the protection policy, wherein the repositories includes at least one of a local 
repository and a remote repository (see Parker et al . 7:44-59 and 9:23) 

wherein the protection policy is configured to be uniquely defined for each 
set of files (see Parker et al . 7:24-35. The protection policy is uniquely defined for 
the set of files to be captured. Also see 8:32-9:31 , which lists out several different 
groups of files, and explains how a user can set options for each group). 

Parker et al . does not teach capturing a snapshot of the set of files at a 
particular point in time 

Maintaining a list of modified and/or created files since last captured 
snapshot 

Zavas et al . teaches capturing a snapshot of the set of files at a particular 
point in time (see Zavas et al . 7:16-46); 
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Maintaining a list of modified and/or created files since last captured 
snapshot (see Zavas et al . 5:31-40 and 7:16-46); 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have modified Parker et al . by the teaching of 
Zavas et al ., because Zavas et al . provides Parker et al. the benefit of insertion 
and removal of entries in the MFL are performed by the storage system. When 
the first of a file's data and metadata bits are turned on, the storage system adds 
the file to the MFL. In this way, a file is added only once to the MFL (see 7:40-45) 
which greatly reduces the already low computer system overhead imposed by 
MFL maintenance (see 8:2-4). 

Parker et al . and Zavas et al . do not teach: 

wherein a storage location and a number of replicas of the version of the 
file can be configured to change over time. 

Fujibavashi teaches wherein a storage location and a number of replicas 
of the version of the file can be configured to change over time (see paragraphs 
[0019]-[0020]). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have modified Parker et al . and Zavas et al. 
by the teachings of Fujibavashi , because Fujibavashi provides Parker et al . the 
benefit of locating data backups remotely, so that a customer can survive a 
disaster by restoring data using backed up data mirrored in a remote location that 
was unaffected by the disaster (see Fujibavashi paragraph [0002]). 
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As to claim 8, Parker et al . teachers wherein the file is configured to have 
at least one version (see Parker et al . 8:1 7-25 and Zavas et al . 6:65-7:1 5). 

As to claim 9, Parker et al . teaches applying reverse delta compression to 
the versions of the file when a successive version of the file is stored in the 
repository (see Parker et al . 9:54-10:4). 

As to claim 10, Parker et al . teaches wherein the step of applying reverse 
delta compression comprises: 

Creating another version of the file, wherein the another version of the file 
is in a version of the file successive to the version of the file (see Parker et al . 
9:54-10:4); 

Replicating the another version of the file into the local repository and the 
remote repository (see Parker et al . 6:42-59 and 9:54-10:4); 

Replacing the replicated version of the file in the local repository with a 
reverse delta compressed version representing a difference between the version 
of the file and the another version of the file and replicating (see Parker et al . 
9:54-10:4); 

Transmitting the reverse delta compressed version to the remote 
repository (see Parker et al . 6:42-59. A reverse delta can be sent with the data 
with the shipping container as well as a forward delta); and 

In the remote repository, replacing the version of the file with the reverse 
delta compressed version to store the another version and the reverse delta 
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compressed version (see Parker et al . 6:42-59 and Zavas et al . 7:25-32. A 
reverse delta can be sent with the data with the shipping container as well as a 
forward delta). 

As to claim 13, Parker et al . teaches wherein examining a protection policy 
associated with the set of files to determine where and how to protect files 
associated with the set of files comprises: 

Determining whether to keep a version history of a file in the set of files 
(see Zavas et al . 7:25-40 and Parker et al . 9:54-10:4). 

As to claim 14, Parker et al . teaches wherein examining a protection policy 
associated with the set of files to determine where and how to protect files 
associated with the set of files comprises: 

Determining a specified backup frequency for a repository (see Parker et 
al. 8:17-25 and 9:6-11). 

As to claim 15, Parker et al . teaches wherein examining a protection policy 
associated with the set of files to determine where and how to protect files 
associated with the set of files comprises: 

Determining a specified type of compression for a file in the set of files 
(see Parker et al . 6:42-59. A reverse delta can be chosen along with a forward 
delta to send to the library). 
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As to claim 16, Parker et al . teaches wherein examining a protection policy 
associated with the set of files to determine where and how to protect files 
associated with the set of files comprises: 

Determining a specified caching level of a repository (see Parker et al . 
9:12-14. A storing (caching) frequency level is determined and chosen). 

As to claim 26, Parker et al . as modified teaches wherein the fileserver 
further includes: 

backup means for backing up the modified files into repositories identified 
in the protection policy based on the backup frequency (see Parker et al . 9:6-1 1 ); 

Storage means for storing a latest version of a file in a repository where a 
prior version of the file is stored (see Parker et al . 9:54-1 0:4); 

Means for determining a difference between the latest version of the file 
and the prior version of the file (see Parker et al . 9:54-1 0:4); 

Means for applying reverse delta compression of the difference (see 
Parker et al . 9:54-10:4); and 

Means for replacing the prior version of the file with the reverse delta 
compressed difference between the latest version and the prior version of the file 
(see Parker et al . 9:54-10:4). 



6. Claims 11-12 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Parker et al . (US Patent 6,847,982) in view of Zavas et al . (US Patent 
6,560,615), in view of Fuiibavashi (US Pre-Grant Publication 2003/0131278) , 
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and further in view o f Santrv et al . ("Deciding when to forget in the Elephant file 
system"). 

As to claim 11, Parker et al . as modified teaches wherein examining a 
protection policy associated with the set of files to determine where and how to 
protect files associated with the set of files comprises: 

Determining the location of repositories (see Parker et al . 10:36-55) 

Parker et al . does not teach and a number of replicas of the files to be 
stored in each repository. 

Santrv et al . teaches a number of replicas of the files to be stored in each 
repository (see page 113, section 3.3. Only one version is kept). 

Therefore, it would have been obvious to one of ordinary skill at the time 
the invention was made to have further modified Parker et al . by the teaching of 
Santrv et al ., since Santrv et al . teaches the benefit of old versions of files being 
automatically retained and storage is managed by the file system. Users specify 
retention policies for individual files, groups of files, or directories. The goal of 
Elephant is to allow users to retain important old versions of all of their files. User 
actions such as delete and file write are thus easily revocable by rolling back a 
file system, a directory, or an individual file to an earlier point in time (see page 
111, last paragraph of section 1 ). 

As to claim 12, Parker et al . as modified teaches the method of claim 7. 
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Parker et al . as modified does not teach wherein examining a protection 
policy associated with the set of files to determine where and how to protect files 
associated with the set of files comprises: 

Determining whether to purge a file from a repository after the file has 
been deleted from a set of files. 

Santry et al . teaches wherein examining a protection policy associated 
with the set of files to determine where and how to protect files associated with 
the set of files comprises: 

Determining whether to purge a file from a repository after the file has 
been deleted from a set of files (see page 113, section 3.5 and 115, section 4.2.3 
(it is determined whether a file should be deleted)). 

Therefore, it would have been obvious to one of ordinary skill at the time 
the invention was made to have further modified Parker et al . by the teaching of 
Santry et al ., since Santry et al . teaches the benefit of old versions of files being 
automatically retained and storage is managed by the file system. Users specify 
retention policies for individual files, groups of files, or directories. The goal of 
Elephant is to allow users to retain important old versions of all of their files. User 
actions such as delete and file write are thus easily revocable by rolling back a 
file system, a directory, or an individual file to an earlier point in time (see page 
111, last paragraph of section 1 ). 

7. Claim 19 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Whiting et al . (US Patent 5,778,395), in view of Fuiibavashi (US Pre-Grant 
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Publication 2003/0131278) , in view of Zavas et al . (US Patent 6,560,615), and 
further in view of Burns et al . ("Efficient Distributed Backup with Delta 
Compression"). 

As to claim 19, Whiting et al as modified teaches: 

Backup said modified files into repositories identified in said protection 
policy based on said backup frequency (see Whiting et al . 5:2-8 and 33:49-51); 

Store a latest version of a file in a repository where a prior version of said 
file is stored (see Whiting et al . 8:21-31 ); 

Determine a difference between said latest version of said file and said 
prior version of said file (see Whiting et al . 8:21 -31 ); 

Whiting et al . as modified does not teach to apply reverse delta 
compression to said difference; 

Burns et al . teaches to apply reverse delta compression to said difference 
(see Burns et al . section 4.2); 

Whiting et al . as modified teaches replace said prior version of said file 
with said reverse delta compressed difference between said latest version and 
said prior version of said file (see Burns et al . section 4.2). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to have further modified Whiting et al . by the 
teaching of Burns et al ., because Burns et al . teaches the benefit of using delta 
compression algorithms, which minimally encode a version of a file using only the 
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bytes that have changed, such that a backup system can compress the data sent 
to a server (see Abstract). 

Response to Arguments 

8. Applicant's arguments filed 10 June 2009 have been fully considered but 
they are not persuasive. 

Applicants state that they "reiterate and incorporate herein by reference 
Applicants' arguments submitted on February 6, 2008 and November 21, 2008." 
In response to this argument, it is noted that the arguments of 6 February 2008 
and 21 November 2008 were responded to in the Office Actions of 29 May 2009 
and 17 February 2009, respectively. 

Applicant argues that "since Whiting is not capable of storing multiple 
replicas of files in different locations, it fails to disclose that the number of 
replicas stored in each repository can be configured to change over time as well". 
In response to this argument, it is noted that Whiting et al . is not relied upon to 
teach this limitation. Fujibavashi is relied upon to teach this limitation. 

Applicant then recited several advantages of the current invention. In 
response to applicant's argument that the references fail to show certain features 
of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., "file servers that are the source of data to be backed up by having historical 
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versions of data stored into a local site repository and a peer remote repository;" 
"a filter driver that can, in real time, capture changes as they occur so that there 
is no need to "walk" file system;" maintaining "the history of all changes to a file 
over time, within the specific retention period and does not implement single 
instance storage;" having a "backup administrator to specify how many replicas 
of data need to be maintained in onsite and offsite repositories;" creating "for 
each share on each source fileserver, a protection policy ... that includes backup 
frequency, retention/purging and version management rules;" and "having a 
backend collection of peer repositories distributed across multiple sites;") are not 
recited in the argued claim. Although the claims are interpreted in light of the 
specification, limitations from the specification are not read into the claims. See 
In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

Applicant argues that Fujibavashi "fails to cure the deficiencies of Whiting 
with regard to this element," adding that "Fujibayashi fails to address the problem 
of having storage location and number of replicas in each of its storage locations 
changing over time". In response to this argument, as noted in the Office Action, 
Fujibavashi teaches wherein a local snapshot repository and a remote snapshot 
repository, which contains a mirror of data of a corresponding local snapshot. 
These are different repositories. As time goes on, the local and remote 
repositories add volumes to contain more replicas of data. These volumes 
constitute different locations in memory (see paragraphs [0019]-[0020]). 
Therefore, as more volumes are added, the locations at which replicas are stored 
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changes. As such, Fuiibavashi fully meets the claimed limitation "two or more 
repositories are configured to store a replica of a file, wherein a storage location 
and a number of replicas in each repository can be configured to change over 
time". The location and number of replicas in each repository increases as time 
increase. Thus, the location and number of replicas in each repository "can be 
configured to change over time". 

Applicant then states that "an advantage of the present invention is that it 
is configured to separate fileservers and repository nodes, where data is to be 
protected. The present invention maintains repository copies on separate disk 
drivers located on separate servers and transmits backup data continually 
between repositories." It is noted that these limitations do not exist in the 
independent claims. 

Applicant argues that "the ability to change the storage location and the 
number of replicas in each repository cannot be changed over time". In response 
to this argument, it is noted that Fuiibavashi teaches this limitation, as noted 
above. It is also noted that Whiting et al . does not "teach away" from storing 
multiple copies of a file in multiple repositories. It simply teaches storing a single 
copy of a duplicate file in single backup means. Fuiibavashi seeks to solve the 
problem wherein a disaster may occur at the backup means by providing multiple 
places to store a single file. 
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Applicant also argues that "Whiting fails to disclose that these created or 
modified files are replicas of a single file. In contrast, Whiting stores only a single 
copy of the file". In response to this argument, it is noted that a single copy of a 
file is a replica of the file. It is also noted that Whiting et al . is not relied upon for 
storing multiple copies of a file. As stated above, Fuiibavashi teaches this 
limitation. 

Applicant also argues that "It appears that Whiting includes a backup 
administrator that configured the backup system using administrator software 
function provided as part of Whiting's product. The backup is then ran by a 
backup agent process for a network node that is selected by the backup 
administrator. However, Whiting fails to disclose that it has a protection policy 
uniquely defined for each share of data on the fileserver." In response to this 
argument, it is noted that each node may schedule its own backups 
independently (5:6-8). It is also noted that each node has a share of data on the 
backup server (7:8-31). This, each share of data may have a unique backup 
schedule configured. 

Applicant argues that Zayas fails to cure the deficiencies of Whiting. 
Applicant specifically argues that "the combination of all three references still fails 
to address having two or more repositories configured to store a replica of a file, 
wherein a storage location and a number of replicas in each repository can be 
configured to change over time as ell as the filter driver capturing the snapshot at 
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a specified time interval based on a backup frequency defined in a protection 
policy stored in the fileserver, wherein the protection policy uniquely defined for 
each share of data on the fileserver". It is noted that both of those arguments was 
responded to above. 

Applicant then argues that Belknap et al . and Burns et al ., in combination 
with Whiting et al ., Fujibavashi , and Zavas et al ., do not teach the subject matter 
of claim 1 . In response to this argument, it is noted that neither Belknap et al . nor 
Burns et al . were relied upon to teach the subject matter of claim 1 . 

Applicants then argue that "on page 20, the Examiner provided an 
incomplete response to Applicants' arguments concerning the above 
combinations of Whiting, Fujibayashi, Zayas, Belknap, and Burns. Applicants 
respectfully request clarification of the Examiner's submission. Should the next 
office action be made final, Applicants respectfully petition withdrawal of its 
finality due to the incompleteness of the present office action." In response to this 
argument, the Examiner has reviewed page 20 of the Office Action of 17 
February 2009, and is uncertain exactly which argument had an incomplete 
response. No arguments in regards to Belknap et al .. Burns et al .. or Fujibavashi 
can be found on page 20. In addition to this, all arguments on that page appear 
to have been responded to completely. 
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In regards to Parker et al .. Applicant argues that the teachings of Parker et 
al. are "different than replicating the version of the file to two or more repositories 
specified by the protection policy, wherein the repositories include at least one of 
a local repository and a remote repository, wherein a storage location and a 
number of replicas of the version of the file can be configured to change over 
time." In response to this argument, it is noted that Parker et al . teaches a Vault 
to store captured files from a workstation / server. This is a "local repository." The 
Vault then sends the data, "at regular intervals", to an offsite Library system. This 
is a "remote repository" (see Parker et al . 7:44-59). It is noted that Fuiibavashi is 
relied upon for the final limitation. 

Applicant then argues that "Parker's policy is not uniquely defined for each 
set of files, contrary to the recitation of the amended claim 7." In response to this 
argument, it is noted that the status of claim 7, as submitted on 10 June 2009, is 
"previously presented". There are no amendments identified in the claims. It is 
also noted that Parker et al . teaches a uniquely defined protection policy for each 
set of files to be captured (see 7:24-35. A user may "determine those files that 
are critical to their particular business function and capture only those files that 
are important enough to be captured"). Also see 8:32-9:31 , which lists out 
several different groups of files, and explains how a user can set options for each 
group. 
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Applicant argues that "The combination of Parker, Fujibayashi, and Zayas 
still fails to disclose all elements of claim 7 including, but not limited to," 
whereupon Applicant lists out the subject matter of claim 7. In response to this 
argument, it is noted that the combination of Parker et al ., Fujibayashi , and Zayas 
eta!., does teach those limitations, as recited in the office action above. 

Applicant argues that "Santry also fails to cure the deficiencies of either 
Parker, Fujibayashi, Zayas, or their combination" in regards to claim 7. In 
response to this argument, it is noted that Santry et al . is not relied upon to teach 
the subject matter of claim 7. 



9. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of 
time policy as set forth in 37 CFR 1 .1 36(a). 

A shortened statutory period for reply to this final action is set to expire 
THREE MONTHS from the mailing date of this action. In the event a first reply is 
filed within TWO MONTHS of the mailing date of this final action and the advisory 
action is not mailed until after the end of the THREE-MONTH shortened statutory 
period, then the shortened statutory period will expire on the date the advisory 
action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be 
calculated from the mailing date of the advisory action. In no event, however, will 
the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 



Conclusion 
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Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to CHARLES D. ADAMS whose telephone 
number is (571)272-3938. The examiner can normally be reached on 8:30 AM - 
5:00 PM, M - F. 

If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Charles Rones can be reached on (571) 272-4085. The 
fax phone number for the organization where this application or proceeding is 
assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll- 
free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786- 
9199 (IN USA OR CANADA) or 571-272-1000. 



/C. D. A./ 

Examiner, Art Unit 2164 
/Charles Rones/ 

Supervisory Patent Examiner, Art Unit 2164 



